COMMUNICATION SYSTEM ARCHITECTURE FOR VOICE FIRST 

COLLABORATION 



FIELD OF THE INVENTION 

This invention relates in general to network implemented shared workspace 
environments, and more specifically to an apparatus and method for spontaneously setting up, 
between physically distant individuals, a collaborative work-sharing environment. 

BACKGROUND OF THE INVENTION 

Well known examples of collaborative work-share environments include video 
conferencing; document sharing (read only or write access); and shared ^Nvhiteboard" 
systems. The majority of videoconference meetings are currently implemented using 
expensive, dedicated equipment such as manufactured by PictureTel™. Typically, such 
equipment provides not only video conferencing, but also other virtual co-location tools. 
Because of its cost and size, this equipment is typically located in a dedicated 
'Videoconference room", rather than at individual users' desktops. Such systems are used, 
primarily, as a means of reducing operating costs, such as air travel for the purpose of 
conducting face-to-face meetings. 

Recently, much more economical, PC-based products have been introduced to the 
market. Examples of current products that can be used to create a shared working 
environment include Intel Corporation's ProShare™ and Microsoft Corporation's 
NetMeeting^. These PC-based products are relatively low cost (in some cases firee of charge) 
and are sufficiently small as to enable mass deployment on every networked PC of an 
enterprise LAN. Unlike dedicated conference room equipment, PC-based products can be 
viewed as workplace enhancements, providing added value to personal communications, 
rather than as tools for corporate cost reduction. 

In spite of the cost and space advantages of PC-based systems over prior art dedicated 
conferencing facilities, the PC-based products are difficult to use, especially for the majority 
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of users who have no technical background or training. Setting up a collaborative session 
using existing PC-based technology typically involves cumbersome setup processes, 
including establishing IP-addresses, launching software etc, and are often scheduled for a date 
and time subsequent to the telephone discussion in which the parties agree to conduct the 
video conference. Furthermore, during the actual setup process, no intrinsic voice 




communications path exists between the parties involved. Voice communication can not take 
place until the setup process is complete. Using current technology, it is not uncommon for 
the parties to make a regular phone call in order to talk through the setup process. 

SUMMARY OF THE INVENTION 

According to the present invention, a system is provided for initiating a collaborative 
work-share environment between two or more parties to a telephone call, without complex 
and time consuming setup processes as are common in the prior art. In accordance with the 
preferred embodiment, each party to a telephone call is provided with a collaboration button 
and an indicator on their telephone set. When the indicator is illmninated, the system is 
capable of establishing a work-share environment. In response to one of the parties activating 
the collaboration button, the system causes network enabled applications to run on the 
individual users' desktop computers so that the parties are able to share information between 
themselves, conduct a video conference, etc., while maintaining their initial voice connection. 

Thus, the telephone is used in the usual way to make regular, voice-only, telephone 
calls. Once a call is established, the telephones communicate with each other to determine if 
they each are associated with equipment which would allow richer collaboration between 
their respective users. If such equipment is available then the indicator on at least one of the 
telephones is lit, indicating that richer collaboration is possible. If the talking parties decide 
that they would like to share a document or set up a video conference, this may be initiated by 
either party pushing the collaboration button. 

Once the button has been pushed, one of a nxmiber of subsequent scenarios are 
possible. In all cases, from a user perspective, the voice path is unaffected and the talking 
parties may continue uninterrupted conversation. 

Some implementation examples are set forth below, without limitation to the scope of 
the invention. In its broadest aspects, the present invention is a method and apparatus for 
simple spontaneous setup of a shared workspace. 

BRIEF DESCRIPTION OF THE DRAWINGS 

A preferred embodiment of the present invention is described herein below with 
reference to the drawings in which: 

Figure 1 is a diagram illustrating a preferred station arrangement including a 
telephone and a desktop PC, both of which are connected to a LAN; 




Figure 2 shows the overall architecture of the system according to the preferred 
embodiment; 

Figure 3 is a flowchart showing steps in a call setup according to the method of the 
present invention; 

Figure 4 is a flowchart showing steps for indicating at a telephone set availability of 
network collaboration between multiple parties following call setup; 

Figure 5 is a flowchart showing steps for ceasing the indication of network 
collaboration availability when the call between multiple parties is being tom down; 

Figure 6 is a flowchart showing steps for implementing network collaboration 
between multiple parties according to the invention; and 

Figure 7 shows a generalized architecture of the system according to the invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

Referring to Figure 1, the preferred station arrangement comprises a telephone 1 and a 
PC 3, both of which are connected to a LAN 5 (Local Area Network). The telephone 1 is a 
component of an IP (Internet Protocol) based PBX system. In such a system, telephones, PBX 
hardware components, PCs and other data systems are interconnected via the LAN 5. 

Critical user interface characteristics of the telephone 1 include a collaborate indicator 
7, which can be in the form of an LED or other suitable visual indicator, and a collaborate 
button 9. The collaborate indicator 7 signals to the user that the party (or at least one party in 
a multiparty call) has the capability of collaborating with the user. The user may operate the 
collaborate button 9 if he or she wishes to run a collaboration application. 

The term "collaboration", as used in this specification, refers to one of a number of 
desktop collaboration application programs, excluding voice, which allow for enhanced 
communication between one or more people via their desktop computers (PCs). The term 
"virtual co-location" will be used to describe the capability of these applications. Such 
applications typically run on the PC 3 at a user's desktop, or at least have their user interfaces 
on the desktop PC 3. Examples of such applications include video conferencing; multiple 
viewing access via remote PCs to a single document; PC based joint document editing; 
network "white boarding", etc. The operation of these collaboration application programs is 
beyond the scope of this specification although the structure and operation thereof would be 
well known to a person of ordinary skill in the art. 




A collaboration control program runs on each PC 3 associated with a telephone 1. 
This program has the capability of communicating over the LAN 5 with the phone 1 to 
control the collaborate indicator 7 and sense actuation of the collaborate button 9. The 
collaboration control program includes a list of all collaboration application programs 
installed which have been registered with the collaboration control program on the PC 3, 
including information about their capabilities and communication protocols (e.g. H.323). The 
collaboration control program has the capability of launching a collaboration application 
program, or, in the event that it is already running in the backgroxmd, to bring the 
collaboration application program to the foreground. This is accomplished using well known 
capabiUties of the PC Operating System. 

The collaboration control program also has the ability to communicate with the 
collaboration control programs of remote PCs via the LAN 5. It has the capability to request 
(or respond to a request for) a list of collaboration application programs from a remote PC via 
the PC's Operating System. Finally, it has the capability to compare remote and local 
collaboration application programs and, by comparing supported protocols, determine 
whether the mutual collaboration application programs can inter-operate in a shared work 
environment. 

With reference to Figure 2, two similar stations ("Station 1" and "Station 2"), of the 
variety shown in Figure 1, are interconnected over the LAN 5 and are supported by a 
common call control unit 1 1 for implementing various telephony applications. Operation of 
the call control imit 1 1 is beyond the scope of this disclosure, although the structure and 
operation thereof would be well known to a person of ordinary skill in the art. The call 
control unit 1 1 includes a plurality of Phone Proxies (software objects), respective ones of 
which are associated with telephones registered to the system. Each Phone Proxy maintains 
the call state for an associated telephone and includes a database containing both the 
telephone Number and IP Address of the phone as well as the IP address of any PC associated 
with the Phone (i.e. on the same user's desktop). This IP address is typically registered once, 
at the time of system installation. 

Figure 3 illustrates only the basic steps of a call setup, call progress tone generation 
(dial, ringback, busy) having been omitted for ease of explanation. Also, normal call control 
exceptions (e.g. Called Party Busy, No Answer, etc.), and error handling routines, have also 
been omitted. The terms "Phone- 1" and "Phone-2" refer to combinations of specific 
telephone hardware and associated control software proxies, wherein Phone- 1 is the calling 




party and Phone-2 is the called party. After Phone-1 goes off-hook and the caller dials the 
number of the party at Phone-2, Phone-1 sends the dialed digits to the Phone-1 Proxy running 
in Call Control Unit 11. Once the Proxy recognizes the dialed number, the Phone-1 Proxy 
then initiates call setup with Phone-2. Once Phone-2 goes off-hook, the Phone Proxy(s) send 
the IP address of the Phone-2 voice port to Phone-1, and vice versa, thereby enabling the 
phones to establish duplex voice paths, and the call is completed. 

Initial setup of the collaborate indicator 7 is initiated by a Call Completed event as set 
forth above. The Call Complete event indicates that calling and called parties to an IP voice 
session are "connected". In general, this event occiu-s at both the calling and called party 
Phone Proxies, and again if additional parties are added to build a voice conference. 

As shown in Figure 4, if both parties each have at least one common collaboration 
application program supporting at least one protocol in conmion then the collaborate indicator 
7 is illuminated. Conversely, if the parties do not share a collaboration application program in 
conmion, or the situation is indeterminate, the collaborate indicator 7 will not be illuminated. 
Following a Call Completed event (or multiple Call Complete events if there are multiple 
parties to the call), the Phone-1 Proxy notifies the collaboration control program running in 
PC 3 of the IP address of Phone-2, and requests the IP address of its associated PC. Once 
Phone-2 responds with the requested IP address, the collaborate control program in the PC 
associated with Phone-1 requests information on collaboration application programs 
supported by the PC of Phone-2. More, particularly, Phone-1 requests the list of collaboration 
application programs maintained by the collaboration control program in PC 3 associate with 
Phone-2. Once that information has been received, the local collaborate control program 
compares its list of supported application programs with those supported by the remote PC 
and, in the event of at least one match, sends a message to Phone-1 to illuminate the 
collaborate indicator 7. 

A tear-down process occurs in the event of one party hanging-up on the call (multiple 
hang-up events occurring in the event of a multi-party conference), as shown in Figure 5. The 
phone used by the party which is hanging up notifies Phone-1 of the Hang-up event. Phone-1 
then notifies the collaborate control program of the Hang-up event. The collaborate control 
program determines whether any of the remaining parties to the call can collaborate, in which 
case the collaborate indicators remain illuminated. If there are no remaining parties capable of 
collaboration, or if Phone-1 hangs up, then the collaborate control program for Phone-1 sends 
a message to extinguish the collaborate indicator 7 at Phone-1. Thus, the collaborate indicator 




7 remains illuminated provided that at least one other party remains in the call with the 
capability to collaborate with the initiating telephone (Phone- 1). 

Operation of the collaborate button 9 is set forth with reference to Figure 6, from 
which it will be noted that the button takes no action imless the collaborate indicator 7 is lit. 
In response to user actuation of button 9, Phone-1 notifies its associated collaborate control 
program. If the local indicator 7 is extinguished, then no further action is taken. The step 
"Phone-1 CI lit?", may be omitted in response to user selection. If the local indicator 7 is 
illuminated, the collaborate control program determines whether there is more than one 
collaboration application program available. If not, then the collaborate control program 
laimches or brings the collaboration application to the foregroxmd at the user's desktop. A 
similar message may be sent to the collaborate control program at the remote party so that the 
collaborating applications launch simultaneously. If more than one collaboration application 
program is available, then a dialog box is displayed at the user's desktop PC 3 listing the 
collaboration applications available. Once the user selects an application, program flow 
returns to the collaborate control program for launching the application. 

Referring to Figure 7, a general architecture is presented wherein the LAN is 
generalized to include the Internet 13. In this case. Station 1 and Station 2 can be located 
anywhere geographically provided that they have Internet, or other network access. Non- 
Intemet communications terminals (e.g. terminals located at a private home) are represented 
by Station 3 and Station 4. 

Station 3 is illustrated as a PC with multimedia microphone and speakers and running 
an IP telephony protocol supported by an Intemet Service Provider 15. Interconnection to the 
ISP is via the PSTN (Public Switched telephone Network) using an arbitrary protocol (e.g. IP 
/ PPP / 33.6 Modem or ISDN BRI). In this scenario, the function of the collaboration control 
program may be performed either by the ISP 15 or the PC in Station 3. If Station 1 calls 
Station 3, it will respond provided that it is running H.245 or other suitable protocol. 

Station 4 is shown implementing a Plain Old telephone Service (POTS) termination. 
Station 1 can communicate with Station 4 via a PSTN gateway 17, in a well known manner. 
The gateway 17 may or may not respond to a collaboration control program request from 
Station 1. In any event, the collaboration control program of Station 1 will not recognize 
collaborative capabilities and the collaborate indicator of Station 1 therefore remains un- 
illuminated. 




FAX is, arguably, the third most pervasive form of collaboration (face-to-face 
communication and telephone communication being the first and second most pervasive, 
respectively). Thus, as an altemative Station 3 and/or Station 4 of Figure 7 may have 
associated FAX applications ranging from a FAX machine to FAX emulation software. In 
this case, it is preferred that Station 3 or the ISP 15 and PSTN gateway 17 be implemented in 
such a way as to respond to a capabiHties query by indicating FAX capability. Similarly it is 
preferred that collaboration application program suite on Stations 1 and 2 include FAX 
capability. 

Numerous alternatives and variants of the invention are possible. 

Some or all of the functions described herein as being implemented via the call 
control unit phone proxies may be implemented physically within each telephone 1 (e.g. via a 
H.323 IP Phone). 

Rather than using separate coimections from phone 1 to LAN 5 and PC 3 to LAN 5, 
altemative "one wire to the desktop" configurations may be adopted. In one embodiment, the 
phone 1 is connected directly to the LAN 5 and the PC 3 is connected to phone 1 , such that 
the phone 1 routes or switches PC data streams to/from the LAN 5. In the second 
embodiment, the PC 3 is connected directly to the LAN 5 and the phone is plugged into the 
PC 3, such that the PC routes or switches phone voice traffic to/from the LAN (i.e. the 
telephone is a PC peripheral). 

It is possible to implement either the collaborate indicator 7 or the collaborate button 
9 (or both) on the PC 3. For example, the collaborate indicator 7 could simply be part of an 
application user interface and the collaborate button 9 could be either a soft button activated 
with the mouse or a "fimction" key on the PC keyboard (i.e. similar to a client-server 
architecture). 

The system described herein employs an identifiable call control unit 1 1 (e.g. Server 
PC). It is equally possible that the invention may be applied in a peer-to-peer architecture, 
(e.g. employing H.323 protocol). 

The foregoing description refers mainly to two-party collaboration, however the 
method of this invention is applicable, with minor modifications, to multiparty collaboration. 

The preferred deployment of this invention is in a system in which telephone (voice) 
transport is effected via the data network (e.g. using a corporate LAN, WAN, or the Internet). 
However, such is not a requirement for realizing the invention which, it is contemplated, 
could in principle be implemented on top of dedicated telephone (e.g. PBX, PSTN, ISDN), 
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with data systems to connect telephone and PC at the 
desktop. The telephone 1 and PC 3 may or may not be 
physically connected at the desktop. Further 
architectural detail of this implementation are not 
described but would be well known to a person of ordinary 
skill in the art . 

The present invention can be implemented by remote 
computers connected over a network. Although the 
embodiment described hereinabove has been described with 
reference to a separate telephone, the telephone 
equipment can be integrated within the computer and the 
indicator and collaborative button can be provided by an 
input device of the computer e.g. a keyboard. The voice 
capability of the telephone can be provided by a 
microphone input into the computer as is well known in 
the art. 

Since the present invention can be implemented by a 
computer program operating on a computer, the present 
invention encompasses a computer progrcun and any form of 
carrier medium which can carry the computer program e.g. 
a storage medium such as a floppy disk, CD ROM, 
programmable memory device, or magnetic tape, or a signal 
such as optical signal or an electrical signal carried 
over a network such as the Internet. 

All such alternative embodiments and variations are 
believed to be with the scope of the invention as defined 
by the claims appended hereto . 



